今天先從整個自動化檢查架構講起，我把這個自動化檢查流程叫做 pr-check，寫成一個套件提供不同 repo 的 PR 檢查函式，目前專注於 dbt 的部分，未來可以擴展至其他應用場景。

整個 pr-check 的目錄架構如下：

├── README.md
├── poetry.lock
├── pr_check
│   ├── __init__.py
│   ├── generators
│   │   ├── __init__.py
│   │   ├── html_generator.py
│   │   └── report_templates
│   │       └── dbt_pr_report.html
│   ├── handlers
│   │   ├── __init__.py
│   │   └── pr_handler.py
│   └── operators
│       ├── __init__.py
│       ├── bigquery_operator.py
│       ├── dbt_operator.py
│       └── git_diff_operator.py
├── pyproject.toml
└── tests
    ├── __init__.py
    ├── test_bigquery_operator.py
    ├── test_dbt_operator.py
    ├── test_git_diff_operator.py
    └── test_html_generator.py

pr-check 主要由以下三個模組組成：

1. Generators：負責產生檢查報告，使用模板生成 HTML 檔案。
2. Handlers：負責將生成的檢查報告發送至 PR 頁面。
3. Operators：負責與 dbt、BigQuery 及 Git 進行交互操作，獲取檢查結果。

接下來將深入介紹這些模組的詳細功能與其運作方式。

Generators

Generators 的主要職責是生成報告。由於最終要將檢查結果傳到 PR 頁面，因此報告的內容與格式至關重要。我們首先決定報告中需要包含哪些關鍵資訊，接著使用模板來編排這些內容。

• html_generator：使用 Jinja 語法來建立動態模板，能夠根據不同的檢查結果生成架構一樣的報告。模板文件位於 report_templates 資料夾中，dbt_pr_report.html是專門針對 dbt 檢查報告進行設計的模板。

Handlers

Handlers 模組的核心任務是將已生成的檢查報告推送到 PR 頁面，讓 developer 和 reviewer 都能在 Azure DevOps Pull Request 頁面中查看。

• pr_handler：該模組中的 pr_handler.py 負責與 Azure DevOps API 進行交互。它將生成的 HTML 檔案轉化為 PR 的評論內容，並自動發送至對應的 PR 頁面，實現檢查報告的即時展示。

Operators

Operators 模組是整個 pr-check 的核心部分，負責從各種來源（如 Git、dbt 和 BigQuery）提取數據，並進行必要的檢查和對比。

• git_diff_operator：該模組通過比對 PR 與主分支（master）的異動，提取變更的檔案列表，為後續操作提供依據。
• dbt_operator：此模組負責解析 dbt 的 manifest 檔案，並根據 PR 中的變更篩選出相關的 dbt models。讓我們專注於那些受變更影響的數據模型。
• bigquery_operator：該模組生成 SQL 查詢，用於檢查欄位型態變更、欄位增減及數據量異動。查詢結果將直接通過 BigQuery API 返回，供報告生成器使用。

以上就是整個 pr-check 套件的架構，接下來就會更詳細介紹每個模組的細節。